• Overview: Most entities relate (are associated to) other entities; Can relate one-to-many (1:N) or many-to-many (N:N); Relationships have cascading rules; Can map fields between entities to ease data-entry and improve data quality
• One-to-many (1:N): Occurs between a primary (parent) record (the "1") and many related (child) records (the "N"); Each child record can only be linked to one primary record; When creating a 1:N relationship, CRM creates a lookup field on the child entity to store parent record's GUID (the lookup is not automatically added to the form); N:1 (many-to-one) is the same as 1:N, it depends on which "end" of the relationship is being considered; You can modify the relationship from the parent or child entity; Remember: Just as in the real world, a child looks up to a parent, so the child record will have a lookup field to the parent record.
  • Relationship Definition
    • Primary Entity: The entity for which there is one record in each relationship. (e.g., The Product in a Product Review record is the primary entity because a Product Review is for one product.)
    • Related Entity: The entity for which there are many records in each relationship.
    • Name: Schema name for the relationship. Typically, the primary entity name comes first (e.g., new_product_productreview)
    • Searchable: Usually set to Yes; affects Advanced Find, whether user can search for related records
  • Lookup Field
    • Display Name: The label for the lookup field that CRM creates for the relationship
    • Name: Schema name for the lookup field; Usually the name of the primary entity with "id" at the end (recommended); Can change it to be more descriptive
    • Field Requirement: Sets whether the field is required; if the related entity can only exist in context with a parent entity (e.g., Product Review cannot exist without a Product) then set to Business Required
    • Description: Description for the lookup; Displayed as a tooltip
  • Navigation Pane Item for Primary Entity
  • Relationship Behavior
  • Field Mapping: When mapping Option Sets, a matching integer must exist for the target, otherwise the target is left blank (it's better to use global option sets if mapping is likely);
• Many-to-many (N:N): See example 1 below: There can be multiple competitors for an opportunity and a competitor can be related to several opportunities.
  • Before creating a N:N relationship between entities, consider whether linking records with a Connection is a better choice or whether manually creating your own junction or intersecting entity would better meet your needs. See Richard Knudson's blog post on this to help with this decision.
  • Can create N:N between system and custom entities; Not every system entity can be in a N:N; When creating an N:N, CRM creates an intersect (link) entity in the database;
  • Native N:N: CRM creates a hidden intersect entity with N:1 from the intersect entity to the two linked entities; Intersect entity: cannot be customized, no new fields, cannot query it directly (only through SDK), cannot use in Workflow, always enabled for auditing. No lookups are created on either end. Privileges are controlled by related entities (users must have Append and Append To privileges), not for the intersect entity.
  • Manual N:N: Use a custom entity with two lookup fields to bridge the entities; Can add custom fields to intersect entity to store additional details; More work is needed to create suitable views/grids
  • See also: Connections

Example 1: Account to Primary Contact (1:N)

This entity relationship diagram shows some of the relationships between account, contact, opportunity, etc. The screen to the right shows the relationship details for the 1:N from the Account entity to the Contact entity.

Deciding on an Entity Relationship Type

Here are some examples of the thought process for deciding what entity relationship to create.

What are the entities you want to relate?
Entity 1:		Product
Entity 2:		Product Review
Should Entity 1 (Product) have a lookup to Entity 2 (Product Review) on its form?		No
Should Entity 2 (Product Review) have a lookup to Entity 1 (Product) on its form?		Yes

You need a 1-to-many (1:N) relationship from Entity 1 to Entity 2. Or, you can create a many-to-1 from Entity 2 to Entity 1.

What are the entities you want to relate?
Entity 1:		Student
Entity 2:		Course
Should Entity 1 (Student) have a lookup to Entity 2 (Course) on its form?		No
Should Entity 2 (Course) have a lookup to Entity 1 (Student) on its form?		No

You need a many-to-many (N:N) relationship, either Native or Manual. Create a manual N:N relationship if, for example, you need to track an assigned asset (e.g., microscope) to the student for the course. Or perhaps the student can indicate a rating for the course.

Illustration for the 1:N Product to Product Review example above:

1:N Relationship Behavior

• Relationship behavior refers to whether certain actions that are performed on the primary entity cause the same actions to occur on related entities.
• Parental Relationship: One or more actions that are performed on the primary record are also performed on the related records. For example, if a primary record is assigned, the related records are also assigned.
• Referential Relationship: Actions that are performed on the primary record are not performed on the related records.
• Cascading Behaviors (triggers): These actions trigger 1:N relationship behaviors: Assign, Share, Unshare, Reparent, Delete, Merge (not select-able)
• Cascading Rules:
  • For actions Assign, Share, Unshare and Reparent, the following rules are available: Cascade All, Cascade Active, Cascade User-owned, Cascade None
  • For Delete action: Delete All (delete all related entity records); Remove Link (remove link only; keep related record); Restrict Delete (prevent deletion of primary record if it has child records)
• Types of Behaviors (predefined types of behaviors): Parental, Referential, Referential Restrict Delete, Configurable Cascading
• Other details:
  • A One-to-Many, Custom-to-System cannot be configured as a parental relationship type, only referential.
  • An entity can only have one N:1 parental relationship with another entity. Any other N:1 relationships must be referential. A parental relationship establishes a sense of belonging or exclusivity—the related record belongs to the primary record much more than to any other record.

Field Mapping

• CRM can be configured to copy data from a parent entity record to a related record when creating the related record (from the parent). For example, you might want a company's phone number to be copied to a new contact record.
• Limitations: Must create the related record from the parent; Mapping does not occur when a lookup to a parent is selected; Occurs only one time (not a sync feature)
  • A workflow or plug-in can make up for the limitations in this feature.
• Configuring field mapping: Open the 1:N or N:1 relationship, click Mappings, click New, select source and target fields. Field data types must match and a target field can only be mapped to once.
• Mapping Option Set fields: The integer value of each option set item is used when mapping; If the target field does not have a matching item then the mapping does not occur